Bec'dPCT/PTG 11 FEB 2005 



REGULAR UTILITY PATENT APPLICATION OF 

5 

OLE-IVAR HOLTHE 
FOR 

10 MULTIMEDIA FILE FORMAT 



CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is the US national phase of international application PC17NO03/00325 
15 filed 26 September 2003, which claims priority from Norwegian patent application 
number 20024640 filed 27 September 2002, both of which are incorporated herein by 
reference. 

FIELD OF THE INVENTION 

20 The present invention relates generally to data processing systems, and more particularly 
to a format for holding and/or describing multimedia content that may include program 
instruction code for controlling the playback of the multimedia content. 
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BACKGROUND OF THE INVENTION 

There are many file and/or stream formats in the technical field of the present invention. 
To mention a few: 

• The HTML standard 

5 • The MPEG-4 standard 

• Apple QuickTime Format (US patent number 5,75 1 ,28 1 ) 

• Microsoft ASF Format (US patent number 6,041,345) 

• Macromedia SWF Format (http://www.openswf.org) 

10 These formats are typically used to hold and describe multimedia content for use on the 
Internet. The file or stream based on the format is transmitted over a network to a 
destination computer containing a renderer, which process and renders the content. 
Historically these formats were typically designed and implemented for destination 
computers with good hardware resources (CPU, memory, disk, graphics card, etc.), such 

15 as personal computers (PCs). Typically, most of these formats support media types, 
such as images and text. Some support video, audio, and 3D graphics. 

Conventional file and/or stream formats for holding and/or describing multimedia content 
that may include program instruction code for controlling the playback of the multimedia 

20 content, are limited in several respects. First, these formats typically do not consider that 
the content may need to be used on any class of computer, from computers with very 
limited hardware resources (CPU, memory, disk, graphics card, etc.), to computers with 
powerful hardware resources. Such formats, typically require a renderer implementation 
that will be too large in amount of disk or memory taken up by its program instruction 

25 code, or use too much of the hardware resources, for computers with very limited 
hardware resources (such as handheld devices). Another limitation of such formats is that 
they are generally limited in the lack of flexibility for representing different media types. 
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Such formats use quite limited predefined multimedia content types. They typically do 
not support real 3D graphics (textured polygon mesh), which is important with respect 
to illustrating physical objects in a multimedia rendering. 



5 Yet another limitation of such formats is that they typically cannot contain different 
levels of content scaling for different destination computers. Computers with limited 
resources may not be able to render complex multimedia content combinations. 
Computers with a slow network connection may not be able to download/stream large 
amounts of multimedia data, such as video and audio. With content scaling, it is possible 

10 to maintain multiple representations of the same content for different destination 
computers. A further weakness of these formats is that they do not provide the 
compactness that is necessary for rapid transmission over transport mediums. Such 
formats do not provide streaming capabilities, so that the destination Tenderers can render 
the multimedia content while the multimedia content is being transmitted over the 

15 transport medium. 



SUMMARY OF THE INVENTION 

A format is defined and adopted for a logical structure that encapsulates and/or describes 
20 multimedia content that may include program instruction code for controlling the 
playback of the multimedia content. The multimedia content may be of different media. 
The data of the multimedia content is partitioned into blocks that are suitable for 
transmission over a transport medium. The blocks may include description of the 
multimedia content and/or the multimedia content data. The blocks may also include 
25 program code that may be interpreted and/or executed on the destination Tenderers. The 
blocks may be compressed and/or encrypted. 
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The invention includes a computer system that has a logical structure for encapsulating 
multimedia content that are partitioned into blocks for holding and/or describing the 
multimedia content that may include program instruction code for controlling the 
5 playback of the multimedia content. A computerized method for creating, transmitting, 
and rendering the content, based on the logical structure, is also included. 

In accordance with a first aspect, the invention provides: a method, in a computer system, 
of encapsulating multimedia content data, multimedia content description data, and 

10 program instruction code into an aggregated data representation comprising a logical 
structure, the method comprising storing on a storage device, information about the 
multimedia content data, the multimedia content description data, and the program 
instruction code to form a main header section in the logical structure; storing on the 
storage device, multiple block headers for all multimedia content data, multimedia content 

15 description data, and the program instruction code to form a block headers section in the 
logical structure; and storing on the storage device, multiple data blocks for all multimedia 
content data, multimedia content description data, and the program instruction code to 
form a data blocks section in the logical structure. 

20 In a preferred embodiment the method further comprising determining the storing order of 
the resources, for the different multimedia types, e.g. audio, video, image and text, 
providing efficient streaming transmission; compressing the data in some of the data 
blocks section using appropriate compression schemes, e.g. as ZLIB, PNG or JPEG; and 
providing different scaled content representations of one or more scenes, depending on 

25 different hardware profiles of the destination computers, e.g. bitrate, screen, language, 
and/or machine. 
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In a further embodiment the aggregated data representation or the logical structure are 
transferred across a transport medium to one or more destination computers. Linking 
between multiple files with multimedia content may be accomplished by using an 
externaMink field in the block headers section. 

5 

According to a second aspect, the invention provides, in a computer system, a method of 
retrieving multimedia content data, multimedia content description data, and program 
instruction code from an aggregated data representation stored on a storage device, the 
data representation comprising a logical structure encapsulating the multimedia content 

10 data, multimedia content description data, and program instruction code. The method 
comprising reading from the storage device a main header section of the logical structure, 
the main header section having information about the multimedia content data, the 
multimedia content description data, and the program instruction code; multiple header 
blocks from the header section of the logical structure, the multiple block headers 

15 comprising information about multimedia content data, multimedia content description 
data, and program instruction code; and multiple data blocks from the data section in the 
logical structure, the multiple data blocks comprising multimedia content data, multimedia 
content description data, and program instruction code. 

20 The method may further comprise receiving the aggregated data representation or the 
logical structure across a transport medium on a destination computer, for immediately, or 
at a later time, rendering the content using a renderer. 

In an embodiment the block headers sections comprising a scene block header; the block 
25 headers sections comprising an image resource block header, a text resource block header, 
a mesh resource block header, or a video resource block header; the data blocks section 
comprising a scene data block; the data blocks section comprising an image resource data 



GRI-101/PCT/US 



block, a text resource data block, a mesh resource data block, or a video resource data 
block; the number of data blocks in the data blocks section is equal to the number of block 
headers in the block headers section with an empty external_link field; and the program 
instruction code controls playback of the multimedia content. The logical structure may 
5 be a XML formatted structure. 

In a third aspect the invention provides a computer-readable aggregated data 
representation encapsulating multimedia content data, multimedia content description 
data, and program instruction code, the aggregated data representation comprising a logical 

10 structure stored on a computer readable storage device, the logical structure comprising: a 
main header section comprising information about the multimedia content data, 
multimedia content description data, and program instruction code in a logical structure 
that defines the aggregated data representation; a block header section comprising multiple 
block headers for the multimedia content data, multimedia content description data, and 

15 program instruction code; and a data block section comprising multiple data blocks for all 
multimedia content data, multimedia content description data, and program instruction 
code. The logical structure may also in this case be a XML formatted structure. 

The invention also provides in a further aspect a computer-readable storage medium 
20 holding instructions for encapsulating multimedia content data, multimedia content 
description data, and program instruction code into an aggregated data representation 
comprising a logical structure, according to the method of encapsulating as outlined above. 
Further in another aspect the invention provides a computer-readable storage medium 
holding instructions for retrieving multimedia content data, multimedia content 
25 description data, and program instruction code from an aggregated data representation 
stored on a storage device, the data representation comprising a logical structure 
encapsulating the multimedia content data, multimedia content description data, and 
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program instruction code, the instructions comprising reading from the storage device: a 
main header section of the logical structure, the main header section having information 
about the multimedia content data, the multimedia content description data, and the 
program instruction code; multiple header blocks from the header section of the logical 
5 structure, the multiple block headers comprising information about multimedia content 
data, multimedia content description data, and program instruction code; and multiple 
data blocks from the data section in the logical structure, the multiple data blocks 
comprising multimedia content data, multimedia content description data, and program 
instruction code. 

10 

The present invention employs a format (GX) for holding and/or describing multimedia 
content that may include program instruction code for controlling the playback of the 
multimedia content. A GX file/stream may also be referred to as a GX movie. A GX 
movie may contain one or more scenes, and/or one or more resources, contained in a 

15 block-based structure. A scene specifies the content description and layout data, and/or 
the program instruction code for controlling the playback of the multimedia content. A 
resource may hold specific data items, such as images, text, video, etc. FIG. 14 shows an 
example of two GX files (1400 and 1401). File 1 contains one image resource ("Image 
resource 1"), one scene ("Scene 1"), and links to two resources in File 2. File 2 contains 

20 one image resource ("Image resource 2") and ("Text resource 2"). 

GX is well suited for efficient use on any class of computer, from computers with very 
limited hardware resources (e.g. handheld devices like mobile phones, PDA's and set-top 
boxes for Interactive TV), to computers with powerful hardware resources. GX uses a 
25 block-based format for holding and/or describing multimedia content. Since the block- 
based format is relatively flat and un-complex, in its data structure organization, is easy to 
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process and render on the destination computer. This results in a very small renderer 
implementation, and very low use of hardware resources, on the destination computer. 

GX is flexible with respect to the different media types and/or program code types that it 
5 may contain. The block-based structure of the format makes it easy to extend with a vast 
variety of media types. Depending on the value of the type field, the header and data 
blocks may contain a large number of different media types, limited only by the different 
renderer implementations. GX provides good support for content scaling. The author can 
scale the scene with respect to bitrate (bandwidth), language (Norwegian, English, etc.), 
10 screen (resolution, refresh rate, etc.), and machine (computer class). Furthermore the 
author may split the scaled content into multiple files that are linked together using an 
externaMink field, which is important for rapid loading of a specific content scaling by 
the destination renderer. See example in FIG. 14. The figure illustrates two GX files that 
are linked together using the externaMink. 

15 

GX is very efficient with respect to compactness in holding multimedia content. The 
individual blocks, or data in the blocks, may use different compression schemes, such as 
ZLIB, PNG, or JPEG compression. The author may specify which compression scheme 
to use in the content creation process. 

20 

GX provides streaming transmission, so that the destination Tenderers can render the 
multimedia content while the multimedia content is being transmitted over the transport 
medium. GX uses resources to store the different media types, which the scenes use. See 
examples in FIG. 5, 6, 12, and 13. The figures illustrate how one can contain the 
25 multimedia content types; image, text, mesh, and video, as resources, using block headers 
and data blocks. The resources may be stored in any order by the content creation 
process, which gives the content author the ability to specify in which order the resources 
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should be loaded, when streamed over a transmission medium. This is very important on 
slow transport mediums. See example in FIG. 14. The figure illustrates two GX files that 
are linked together using the external Jink. The two example files contain resources that 
are ordered, and linked together, for efficient streaming transmission. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

Embodiments of the present invention will now be described with reference to the 
following drawings, where: 

FIG. 1 is a block diagram illustrating a computer system that is suitable for practicing the 
10 present invention, 

FIG. 2 is a flowchart illustrating use of the GX format in accordance with an embodiment 
of the present invention, 

FIG. 3 is a block diagram illustrating the components of the GX format in accordance 
with an embodiment of the present invention, 
15 FIG. 4 is a block diagram illustrating the format of the scene_block_header in accordance 
with an embodiment of the present invention, 

FIG. 5 is a block diagram illustrating the format of the image_resource_block_header and 
the text_resource_block_header in accordance with an embodiment of the present 
invention, 

20 FIG. 6 is a block diagram illustrating the format of the mesh_resource_block Jieader and 
the video_resource_block_header in accordance with an embodiment of the present 
invention, 

FIG. 7 is a block diagram illustrating the format of the scene_data_block in accordance 
with an embodiment of the present invention, 
25 FIG. 8 is a block diagram illustrating the format of the image_data in accordance with an 
embodiment of the present invention, 
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FIG. 9 is a block diagram illustrating the format of the text_data in accordance with an 
embodiment of the present invention, 

FIG. 10 is a block diagram illustrating the format of the mesh_data in accordance with an 
embodiment of the present invention, 
5 FIG. 1 1 is a block diagram illustrating the format of the video_data in accordance with an 
embodiment of the present invention, 

FIG. 12 is a block diagram illustrating the format of the image_resource_data_block and 
the text_resource_data_block in accordance with an embodiment of the present invention, 
FIG. 13 is a block diagram illustrating the format of the mesh_resource_data_block and 
10 the video_resource_data_block in accordance with an embodiment of the present 
invention, and 

FIG. 14 is a block diagram illustrating an example of two GX files. 



DETAILED DESCRIPTION 

15 FIG. 1 is a block diagram of an illustrative system for practicing an embodiment of the 
present invention. The present invention can be practiced on computers with very limited 
hardware resources (CPU, memory, disk, graphics card, etc.), to computers with 
powerful hardware resources. Computers with limited hardware resources may be set-top 
boxes for Interactive TV and handheld devices like cellular phones, PDA's and other 

20 devices with CPU and memory, and also PC's with CPU, memory, disk, graphics card, 
and input and output units. FIG. 2 is a flowchart that illustrates the steps that are 
performed in the illustrative embodiment of FIG. 1. The file content, hereinafter called 
GX content (104), is built by an author (step 200 in FIG. 2) and stored on a storage 
medium (102) on a source computer (100). Sometime later, the GX content (104) is 

25 transferred over a transport media (105), such as a network connection, to a destination 
computer (101) (step 201 in FIG. 2). The destination computer (101) includes a number 



GRI-101/PCT/US 



of Tenderers (103) for rendering the multimedia content that are present within the GX 
content (104). For example, the GX content (104) may include program code, image-type 
data and text-type data. The Tenderers (103) at the destination (101) include a program 
code interpreter, an image renderer and a text renderer. The interpreter and the Tenderers 
5 may begin rendering data as soon as they receive data prior to the complete transmission 
of the entire GX content (104) (see step 202 in FIG. 2). The interpreters and the 
Tenderers need not immediately render the data, but rather may render the data at a later 
point in time. 

10 FIG. 3 depicts the basic logical organization of GX content (104). It is up to the author to 
fill in the contents of the GX content in accordance with this format. The GX content 
(104) is divisible into a main header section (300), a block headers section (301) and a data 
blocks section (302). In general, the header sections (300 and 301) are first transmitted 
from the source computer (100) to the destination computer (101) so that the destination 

15 computer may process the information within the header section. Subsequently, the data 
blocks section (302) is transmitted from the source computer (100) to the destination 
computer (101) on a block-by-block basis. 

The main header section (300) as illustrated in FIG. 3 contains information about the GX 
20 content (104). The signature (310) specifies the main type of the GX content, and is 
typically a large number that is unique for a specific authoring environment. The 
byte_count (311) specifies the total number of bytes contained in the GX content (104). 
The block_count (312) specifies the total number of blocks (external or internal) 
contained in, or used, by the GX content (104). The major_version (313), minor_version 
25 (314), major_re vision (315), and minor_revision (316) specifies the version of the GX 
content format. The extra_data (317) provides extra information about the GX content 
(104), depending on the specific implementation of the GX format. The extra_data (317) 
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is optional, and may consist of a variable number of bytes, depending on the specific 
implementation. 

Examples of possible data types are indicated in the figures. Here we use abbreviations 
5 for data types as specified in the C++-programming language, "ulong" is short for 
"unsigned long", "ushort" is short for "unsigned short", "bool" is short for "boolean", 
"string" starts with a unsigned long value indicating the byte count of the string followed 
by the bytes of the UTF-8 character string, "ulonglong" is a 64-bit unsigned long. The 
invention is not limited to the C++ programming language. Other programming languages 
10 may also be used. 

The block headers sections (301) as illustrated in FIG. 3 contain a number of block 
headers that provide information about the GX content (104). The number of block 
headers is specified by block_count (312) in the main header section (300). The 

15 information contained in a block header may vary, depending on the type of content that 
it describes. A block header will always begin with the fields as indicated in FIG. 3. The 
type (320) indicates the type of content that the header describes; this can for example 
indicate a scene, an image resource, or a text resource. The byte_count (321) specifies the 
total number of bytes in the block header. The block_byte_count (322) specifies the total 

20 number of bytes in the associated data block. The name (323) specifies the name of the 
content item. The externaljink (324) specifies a link to the external GX content, in which 
the associated data block is contained. The externaljink is empty if the associated data 
block is contained in the current GX content. The extra_data_l (325) provides extra 
information about the block header and/or content item, depending on the specific 

25 implementation of the GX format. The extra_dataj (325) is optional, and may consist of 
a variable number of bytes, depending on the specific implementation. The specific data 
(326) may contain additional information about the content item. 
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The data blocks section (302) as illustrated in FIG. 3 contain a number of data blocks that 
contain the data of the content items in the GX content. The number of data blocks in the 
GX content is equal to the number of block headers in the GX content with an empty 

5 externaljink. There exists exactly one data block for each block header with an empty 
externaMink in the GX content. The data blocks are specified in the same order, and are 
of the same content type, as the block headers. The type (330) indicates the type of 
content that the data block contains; this can for example indicate a scene, an image 
resource, or a text resource. The byte_count (331) specifies the total number of bytes in 

10 the data block. The name (332) specifies the name of the content item. The extra_data_l 
(333) provides extra information about the data block and/or content item, depending on 
the specific implementation of the GX format. The extra_data_l (333) is optional, and 
may consist of a variable number of bytes, depending on the specific implementation. The 
specific data (334) may contain additional information about the content item. 

15 

The scene content type can be used in GX content to represent the visual layout of 
multiple content items of different types. There can be multiple scenes in one GX file. 
The scene can also be scaled (content scaling) by the Tenderers (103) for different 
representations depending on the characteristics of the destination computer (101). The 

20 scene_block_header (400) as illustrated in FIG. 4 contains the block header data for the 
associated scene data block. The scene_data_block (700) as illustrated in FIG. 7 contains 
the scene data. The type (320 and 330) indicates that the type of the content item is of 
the scene content type. The bitrate_ids (41 1 and 71 1) specifies the bitrate identifiers used 
for content scaling. The bitrate_id_count (410 and 710) specifies the number of bitrate 

25 identifiers. The language Jds (413 and 713) specifies the language identifiers used for 
content scaling. The language _id_count (412 and 712) specifies the number of language 
identifiers. The screen_ids (415 and 715) specifies the screen identifiers used for content 
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scaling. The screen_id_count (414 and 714) specifies the number of screen identifiers. The 
machine_ids (417 and 717) specifies the machine identifiers used for content scaling. The 
machine_id_count (416 and 716) specifies the number of machine identifiers. The 
bitratejds, language_ids, screen_ids 5 and machine_ids, may in an embodiment be of the 

5 unsigned long data type. The extra_data_2 (418 and 718) provides extra information 
about the scene block and/or content item, depending on the specific implementation of 
the GX format. The extra__data_2 (418 and 718) is optional, and may consist of a variable 
number of bytes, depending on the specific implementation. The auto_size (719) 
specifies the layout of the scene inside the scene container. The width (720) and height 

10 (721) specifies the size of the scene. The mouse_pointer (722) specifies how the mouse 
pointer shall appear on the scene. The back_color (723) specifies the background color of 
the scene. The back_style (724) specifies the background style of the scene. The antialias 
(725) specifies antialiasing for the scene. The quality (726) specifies the quality of the 
scene rendering. The frame s_perjcsec (727) specifies the frame-rate of the scene 

15 rendering. The program_code (729) specifies the program code of the scene. The 
program_code may begin with an unsigned long value indicating the byte count of the 
program code, and may be followed by the bytes of the program. The element_count 
(731) specifies the byte count of the element data. The element_data (732) contains 
element definitions for the scene. The extra_data_3 (728), extra_data_4 (730), and 

20 extra_dataj> (733) provide extra information about the scene, depending on the specific 
implementation of the GX format. The extra_data_3 (728), extra_data_4 (730), and 
extra_data_5 (733) are optional, and may consist of a variable number of bytes, depending 
on the specific implementation. The program_code (729) can be in any programming 
language or instruction-set, compiled or source code, depending on the specific 

25 implementation. 
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The program code uses the classes; Scene, Image, Text, Mesh, Video, etc., as specified in 
the Java-language in Appendix B. The classes may implement additional functionality, 
and that there may be more classes, depending on the specific implementation. 



5 The image_data (800) as illustrated in FIG. 8 contain element definition data for the scene 
of the image element type. The text_data (900) as illustrated in FIG. 9 contain element 
definition data for the scene of the text element type. The mesh_data (1000) as illustrated 
in FIG. 10 contain element definition data for the scene of the mesh element type. The 
video_data (1 100) as illustrated in FIG. 1 1 contain element definition data for the scene of 

10 the video element type. The image_data (800), text_data (900), mesh_data (1000), and 
videojiata (1 100) may be contained in the element_data (732) of the scene. The left (805, 
905, 1005, 1105), top (806, 906, 1006. 1106), width (807, 907, 1007, 1107), and height 
(808, 908, 1008, 1108) specify the position and size of the element. The rotation (809, 
909, 1009, 1109) specifies the rotation of the element. The enabled (810, 910, 1010, 

15 1110) specifies whether the element is enabled or disabled. The visible (811,911, 1011, 
1111) specifies whether the element is visible. The transparency (812, 912, 1012, 1112) 
specifies the transparency of the element. The mouse_pointer (813, 913, 1013, 1113) 
specifies how the mouse pointer shall appear on the element. The back_color (814, 914, 
1014, 1114) specifies the background color of the element. The back_style (815, 915, 

20 1015, 1 1 15) specifies the background style of the element. The extra_data_l (804, 904, 
1004, 1 104), and extra_data_2 (816, 916, 1016, 1 1 16) provide extra information about the 
element, depending on the specific implementation of the GX format. The extra_data_l 
(804, 904, 1004, 1104), and extra_data_2 (816, 916, 1016, 1116) are optional, and may 
consist of a variable number of bytes, depending on the specific implementation. 

25 

The image, text, mesh and/or video resource can be used in GX content to contain image, 
text, 3D mesh and/or video data, respectively. The image_resource_block_header (500) as 
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15 



illustrated in FIG. 5 contains the block header data for the associated image resource data 
block. The image__resource_data_block (1200) as illustrated in FIG. 12 contains the image 
resource data. The text_resource_block_header (550) as illustrated in FIG. 5 contains the 
block header data for the associated text resource data block. The 

5 text_resource_data_block (1250) as illustrated in FIG. 12 contains the text resource data. 
The mesh_resourceJ>lockJieader (600) as illustrated in FIG. 6 contains the block header 
data for the associated mesh resource data block. The mesh_resource_data_block (1300) 
as illustrated in FIG. 13 contains the mesh resource data. The 
video_resource_block_header (650) as illustrated in FIG. 6 contains the block header data 

10 for the associated video resource data block. The video_resource_data_block (1350) as 
illustrated in FIG. 13 contains the video resource data. The image_type (510 and 1210) 
specifies the type of the image data. The width (51 1 and 121 1) and height (512 and 1212) 
specifies the size of the image. The bit_count (513 and 1213) specifies the number of bits 
per pixel of the image. The resource_data (1215, 1261, 1311, 1361) specifies the data of 

15 the resource. The resource_data may begin with an unsigned long value indicating the byte 
count of the resource data, and may be followed by the bytes of the resource data. The 
extra_data_2 (514, 560, 610, 660, 1214, 1260, 1310, 1360), and extra_data_3 (1216, 
1262, 1312, 1362) provide extra information about the resource, depending on the specific 
implementation of the GX format. The extra_data_2 (514, 560, 610, 660, 1214, 1260, 

20 1310, 1360), and extra_data_3 (1216, 1262, 1312, 1362) are optional, and may consist of 
a variable number of bytes, depending on the specific implementation. 

The World Wide Web Consortium (W3C) has defined the Extensible Markup Language 
(XML) universal format for structured documents and data on the Web. It is easy to see 
25 that the GX format can easily be represented using XML. Appendix A shows a XML 
Schema (XSD), for representing the GX format, according to the W3C XSD 
specifications. Program code listing A.2 is an example XML document, containing GX 
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formatted content in XML format, based on the XML Schema. The XSD specification in 
program code listing A. 1 specifies the preferred XML representation of GX formatted 
content (GXML). The GXML document may be in text or binary coded form. Typically, 
GXML will be used with more functionality (elements, attributes, etc.) than what is 
5 specified by the XML Schema in program code listing A.l. Any element type in GXML 
may include more elements and attributes that what is specified by the XML Schema (e.g. 
include elements from other XML Schema types). For certain applications, it might be 
preferable to do modest restructuring and/or use different names on some of the elements 
and attributes to accommodate the terminology of the specific application contexts. 

10 

The "<gxml>" and "</gxml>" tag pair will typically mark the beginning and end of the 
GXML document. The tag may include additional attributes (e.g. "version" for marking 
the version). For certain applications, it might be preferable not to include this tag (e.g. 
when the GXML format is encapsulated in other types of XML documents or schemas) 
15 or use a different name that is more appropriate for that particular application. 

The "<head>" and "</head>" tag pair will typically mark the beginning and end of the 
header section of the GXML document. The header section will typically contain 
information about the content. For certain applications, it might be preferable not to 
20 include this tag or to use a different name for this tag that is more appropriate for that 
particular application (e.g. "Descriptor", "DescriptorMetadata", "Description", 
"DescriptionMetadata", "MovieDescriptor"). 

The program code listing A.3 is an example of GXML formatted content header where we 
25 use the word "Descriptor" rather than "Header". We have also defined attribute groups, 
such as "SystemBitRate", "SystemLanguages", "SystemScreen", "SystemMachine", 
"Format" and "ExternalURL". "ExternalURL" will typically use a different name for 
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different applications (e.g. "ExternalLink", "Locator", "ExternalLocator", 
"ResourceLocator", "SceneLocator", "ImageLocator", "MediaLocator"). It may be 
preferable to group the descriptors within a "descriptors" tag. For certain applications, 
the program code listing illustrates a preferred XML representation for the GXML header 
5 section. 

The program code listing A.4 is an example of GXML formatted content header where we 
structure the descriptors under the "descriptors" tag, and the external links under the 
"references" tag. For certain applications, the program code listing illustrates a preferred 
10 XML representation for the GXML header section. 

The "<movie>" and "</movie>" tag pair will typically mark the beginning and end of the 
data section of the GXML document. For certain applications, it might be preferable not 
to include this tag or to use a different name for this tag that is more appropriate for that 
1 5 particular application. 

The program code listing A. 5 is an example of GXML formatted data section where we 
have defined attribute groups, such as "Layout", "Behavior", and "Appearance". For 
certain applications, the program code listing illustrates a preferred XML representation 
20 for the GXML data section. 

The program code listing A.6 is an example of using GXML in a particular application. In 
this example the GXML format has been used as a part of the particular format of the 
application. Such use of formats inside formats is quite common with XML documents. 

25 

Including binary data in XML documents have been an industry problem for some time. 
In GXML we use the "xsihexBinary" type on "HexBinaryData" elements. Similarly, it is 
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also possible to have the "xs:base64Binary" type on "Base64BinaryData" elements, 
alternatively to "HexBinaryData". GXML might also include binary data trailing the 
XML document. 

5 FIG. 14 is an example on how content can be effectively linked together for the purpose 
of efficient transmission of the multimedia content over a slow transmission medium. 
Typically, the main problems with a slow transmission medium are; high access time and 
low transmission rate. The access time is the time from the destination computer requests 
content, until the destination computer initially receives it. The transmission rate is the 

10 rate at which data can be delivered across the transmission medium. The GX format can 
embed many small content items as resources, which reduces the total content transfer 
time on transmission mediums with a high access time. As one can see in FIG. 14, the GX 
files (1400 and 1401) contain multiple data blocks, which contain content items, in each 
GX file. The arrows in FIG. 14 illustrates content linking, using the externaljink (324) 

15 field of the block headers. The externaljink field indicates where the data block is located, 
either in the same file, or an external file. The externaMink field may be an URL. By 
linking multimedia content in this manner, one can have efficient reuse of multimedia 
content between different GX files, while maintaining a minimal number of GX content 
files. Reuse of multimedia content is important, since it can be used to avoid having to 

20 retransmit the same content item multiple times. You do want to avoid retransmission of 
content items on slow transmission mediums. 

While the present invention has been described with reference to an embodiment thereof, 
those skilled in the art will appreciate that various changes in form and detail may be 
25 made without departing from the intended scope of the invention as defined in the 
appended claims. The particulars described above are intended merely to be illustrative 
and the scope of the invention is defined by the appended claims. For example, the 
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present invention may be practiced with a multimedia content format that differs from the 
format described above. Alternative multimedia content formats may include only a 
subset of the above-described fields or include additional fields that differ from those 
described above. Moreover, the length of the values held within the fields and the 
5 organization of the structures described above are not intended to limit the scope of the 
present invention. 
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APPENDIX A 



This appendix contains the code listing for the XSD specification of the GXML format, 
with an example GXML formatted file. 

Program code listing A. 1 : 

<?xml version^ 1.0" encoding="UTF-8"?> 

<xs:schemaxmlns:xs="Mtp://www. w3.org/200 l/XMLSchema M 
elementFormDefault="qualified" attributeFormDefault="\inqualifiecL ,, > 

<xs:element nam.e="gxml"> 

<xs:aimotation> 

<xs:documentation>GXML Do^ 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="liead"> 

<xs:complexType> 

<xs:choice maxOccurs="unbounded"> 

<xs:element name =,, sceneHeader"> 

<xs:complexType> 
<xs:attribute name="name" type="xs:string" use="required7> 
<xs:attribute name="externa.1T.ink" type="xs:string" use="optional , 7> 
<xs:attribute name="bitrateIDs" type="xs:string" use="optional'7> 
<xs:attribute name="languageIDs" type= n xs:string" use="optional'7> 
<xs:attribute name="screenIDs" type="xs:stririg" use- 'optional"/^ 
<xs:attribute name^mactanelDs" type="xs:string" use="optional"/> 

</xs:complexType> 
</xs:element> 

<xs:elementname= n imageResourceHeader M > 
<xs:complexType> 
<xs:attribute name="name" type^^stilng" use="required'7> 
<xs:attribute name- 'externa,! Link" type^'xsistring" use="optionaT/> 
<xs:attribute name- 'imageType" type- 'xs:integer" use="optional M /> 
<xs:attribute name-'width" type="xs:integer" use="optional7> 
<xs:attribute name= n lieight" type- 'xsiinteger" use- 'optionar/> 
<xs:attribute name="bitCount n type="xs:integer" use="optional'7> 
</xs:complexType> 

</xs:element> 

<xs:element name="textResourceHeader n > 
<xs:complexType> 
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<xs:attribute name="name" type-'xsistring" use="required7> 
<xs:attribute name- 'externa.! T nnk" tjn?e- 'xsistring" use="optional"/> 
</xs:complexType> 
</xs:element> 

5 <xs :element najcae= ,, meshResourceHeader"> 

<xs:complexType> 
<xs:attribute name="name" type="xs:string" use= n required"/> 
<xs:attribute name="extema,1T link" type="xs:string n use="optional ,, /> 
</xs:complexType> 
10 </xs:element> 

<xs:element najne=*VideoItesourceHeader"> 
<xs:complexType> 
<xs:attribute name="name" type="xs:string" use="required7> 
<xs:attribute name-'extermlLink" type= M xs:string" use= ,, optional ,, /> 
15 </xs:complexType> 
</xs:element> 
</xs:choice> 
</xs:complexType> 
</xs:element> 
20 <xs:element name="movie"> 

<xs:complexType> 
<xs:choice maxOccurs-'imbounded'^ 
<xs:element name- 'scene"> 
<xs:complex , I l ype> 
25 <xs:sequence> 

<xs:ohoice minOccurs="0" maxOccurs="unbouiided"> 
<xs:element name- 'image"> 
<xs:complexType> 
<xs:attribute name-'name" type="xs:string" use="required7> 
30 <xs:attribute name="resourceName" type="xs:string" use= ,, optionaI , 7> 

<xs:attribute name- left" type="xs:integer" use- 'optionar/> 
<xs:attribute name="top" type="xs:integer" use- 'optionaT7> 
<xs:attribute name- 'width" type="xs:integer" use= M optional"/> 
<xs:attribute name="Iieight" type="xs:integer" use="optionaT/> 
35 <xs:attribute name- 'rotation" type- 'xsrfloat" use="optionaTy> 

<xs:attiibute name- 'enabled" type="xs:boolean" use="optionar/> 
<xs:attribute name="visible" type="xs:boolean n use="optioiial , 7> 
<xs:attribute name="transparency" type="xs:float n use="optionaiy> 
<xs:attribute name-'mousePointer" type- 'xs:integer n use="optional M /> 
40 <xs:attribute name="backColor" type="xs:integer" use="optional7> 

<xs:attribute name= n backStyle" type="xs:integer" use= H optional7> 
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</xs:complex , type> 
</xs:element> 
<xs:element name="text"> 

<xs:complexType> 

5 <xs :attribute name="name" type="xs : string" use="required7 > 

<xs:attribute name="resourceName" type="xs:string" use= ,, optionaI , 7> 
<xs:attribute name- left" type="xs:integer" use="optionaTy> 
<xs:attribute name="top n type="xs:integer" use="optional f 7> 
<xs:attribute name- 'width" type- 'xsiinteger" use- 'optional"^ 

1 o <xs:attribute name-'height" type- 'xsrinteger" use= M optionaI7 > 

<xs:attribute name="rotation" type="xs:float" use- 'optional"^ 
<xs:attribute name="enabled" type="xs:boolean" use="optional M /> 
<xs:attribute name="visible" type= n xs:boolean" use= n optioiial , 7> 
<xs:attribute name- 'transparency" type- ■xsrfloat" use="optionaI'7> 

1 5 <xs:attribute name^'mousePointer" type="xs:integer" use- 'optional7> 

<xs:attribute name="backColor" type="xs:integer" use- 'optionaT7> 
<xs:attribute name= n backStyle" type="xs:integer" use="optional"/> 
</xs:complex r fype> 
</xs:element> 

20 <xs:elementnajne="mesti ,, > 

<xs:complexType> 
<xs:attribute name="name" type="xs:string" use="required7> 
<xs:attribute name-'resourceName" type= ,l xs:striIlg ,, use="optionaI M /> 
<xs:attribute name="left" type- 'xsiinteger" use="optional'7> 

25 <xs:attribute name= M top n type="xs:integer n use="optionaJ M /> 

<xs:attribute name="width" type="xs:integer" use= n optionaiy> 
<xs:attribute rauoae- 'height" type="xs:integer" use="optionaT/> 
<xs:attribute name="rotation" type="xs:float" use="optional , 7> 
<xs:attribute name="enabled n type="xs:boolean" use="optional'7> 

30 <xs:attribute name="visible" type="xs:boolean" use= n optional7> 

<xs:attribute name- 'transparency 1 ' type="xs:float M use= n optional7 > 
<xs:attribute name- 'mousePointer" type="xs:integer" use="optionaT7> 
<xs:attribute name- 'backColor" type- 'xsiinteger" use- 'optional'7> 
<xs:attribute name="backStyle" type="xs:integer" use= ,, optional , 7> 

35 </xs:complex r iype> 
</xs:element> 
<xs:element name="video"> 
<xs:complexType> 
<xs:attribute name-'name" type="xs:string" use="required'7> 

40 <xs:attribute name^'resourceName'' type="xs:string" use="optional , 7> 

<xs:attribute name="left" type="xs:integer" use="optional7> 
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<xs:attribute name="top" type- 'xs:integer" use="optionaT7> 
<xs:attribute name- "width" type= n xs:integer" use- 'optionaT7> 
<xs:attribute name="height" type="xs:integer" use="optional , 7> 
<xs:attribute name= ,, rotation" type= n xs:fLoat" use="optional7> 
5 <xs:attribute name="enabled" type="xs:boolean n use="optionaiy> 

<xs:attribute name="visible n type- 'xs:boolean H use="optional , 7> 
<xs:attribute name^'transparency" type="xs:float" \ise= n optional , 7> 
<xs:attribute name-'mousePointer" type- 'xsiinteger" use="optional"/ > 
<xs:attribute name="backColor" type="xs:integer" use="optionaI"/> 
1 0 <xs:attribute name= ,, backStyle" type="xs:integer" use="optional , 7> 

</xs:complexType> 
</xs:element> 
</xs:choice> 

<xs:element name- 'program"> 
15 <xs:complexType> 

<xs:choice minOccurs- '0" maxOccurs="unbounded"> 

<xs:element name="hexBinaryData" type= H xs:hexBinary7> 
</xs:choice> 

<xs:attribute name="src" type="xs:string" use= ,, optional , 7> 
20 </xs:complexType> 
</xs:element> 
</xs:sequence> 

<xs:attribute name-'name" type="xs: string" use= M required M /> 
<xs:attribute name="bitrateIDs" type="xs:string" use="optionaI , 7> 

25 <xs:attribute name="languageIDs" type="xs:string n use="optional'7> 

<xs:attribute name= M screenIDs" type="xs:string" use="optional7> 
<xs:attribute name="maehineIDs" t^e-'xsistring" use= n optional'7> 
<xs:attribute name- 'autoSize" type="xs:integer" use="optional7> 
<xs:attribute name= M width" type="xs:integer n use="optional , 7> 

30 <xs:attribute name= ,, heigtLt n type="xs:integer" use="optional M /> 

<xs:attribute name-'mousePointer" type="xs:integer" use="optionaT7> 
<xs:attribute name= M backColor" type="xs: string" use- 'optionaT7> 
<xs:attribute name="backStyle" type="xs:integer" use- 'optional"^ 
<xs:attribute name-'antialias" type="xs:integer" use =,, optional H /> 

35 <xs:attribute name- 'quality" type- 'xs:integer" use="optional7> 

<xs:attribute name="framesPerKSec n type="xs:integer" use="optional'7> 
</xs:complexType> 
</xs:element> 

<xs:element name="imageResource n > 
40 <xs:complexType> 

<xs:choice minOccurs= ,, 0 ,, maxOccurs="unbounded u > 
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<xs: element najne="hexBiiiaiyData" type="xs:hexBinary7> 
</xs:choice> 

<xs:attribute name-'name" type="xs:string" use- 'required'7> 
<xs:attribute name="imageType" type="xs:integer" use="optional M /> 
5 <xs:attribute name =,, widtli" type="xs:integer" use= ,, optional , 7> 

<xs:attribute name-'height" type="xs:integer M use-'optionaTy> 
<xs:attribute name-'bitCount" type="xs:integer" use="optional"/> 
<xs:attribute name="src" type="xs:string" use="optional , 7> 
</xs:complexType> 
10 </xs:element> 

<xs:element name="textResource"> 
<xs:complexType> 
<xs:choice minOccurs-'O" maxOccurs- 'unbounded"> 
<xs: element naane-'hexBinaiyData 1 ' type-'xs:hexBinary7> 
15 </xs:choice> 

<xs:attribute name="name" type="xs:string" use =,, requiredy> 
<xs:attribute name-'src" type="xs:string" use="optional , 7> 
</xs:complexType> 
</xs:element> 
20 <xs:element name- 'meshResource f, > 

<xs:complexType> 
<xs:cboice minOccurs="O n maxOccurs="unbounded ,, > 

<xs:element name="hexBinaryData" type="xs:hexBinary7> 
</xs:choice> 

25 <xs:attribute name="name" type="xs:string" use= M required'7> 

<xs:attribute name="src" type="xs:string" use="optionar/> 
</xs:complexType> 
</xs:element> 

<xs:element name- VideoResource n > 
30 <xs:complexType> 

<xs:choice minOccurs- '0" maxOccurs="unbounded"> 

<xs:element name="bexBinaryData" type="xs:hexBinary 4 7> 
</xs:choice> 

<xs:attribute name-'name" type="xs:string n use="required M /> 
35 <xs:attribute name="src" type="xs:string n use="optionar/> 

</xs:complexType> 
</xs:element> 
</xs:cboice> 
</xs:complexType> 
40 </xs:element> 
</xs:sequence> 
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</xs:complex , I^ype> 
</xs:element> 
</xs:scliema> 

5 Program code listing A.2: 

<?xml version="1.0" encoding="UTF-8 n ?> 

<gxml xrnlns:xsi="http://www. w3.org/200 l/XMLSchema-instance n > 
<head> 

<sceneHeader name="Scenel" externa1T»ink="" bitrateIDs=" 56000" languageIDs="0" 
10 screenIDs="0y> 

<unageResourceHeader name="m_Imagel" externa,Unnk="" imageType= M 0" width="5" 
height="5" bitCount="24"/> 

</head> 
<movie> 

1 5 <scene name= n Scene 1 " bitrateEDs= n 56000" languageIDs="0" screenIDs= ,, 0" 

autoSize="0" width="550" height= n 400" mousePointer="O u backColor="0" backStyle="0" 
antialias="0" quality="0" framesPerKSec="2500"> 
<image name= "Image 1" resourceName= M IR_Imagel" left="20" top="20" width="5" 
height="5" rotatioii= M 0" enabled="true" visible="true" transparency="0" 
20 mousePointer="0" backColor="0" backStyle="0"/> 

<program src- '"> 
<hexBiiiaiyData>00000000000000 

OOOOOOOOOf^fEfOffiOOOOOOOOOOOOOOOOOOOOOOOO</hexBinaj^ 
</program> 
25 </scene> 

<imageResource Ilame= ,, ^l_Imagel ,, imageType="0" width="5" height ="5" 
bitCount="24 M src= ,M, > 

<hexBinaiyDaJ^0000000000000000^^^ 
0O0O00O00fSOfEf0fiBTO0O0000000000O00O0O00000</hexBin^ 

30 </imageResource> 

</movie> 

</gxml> 

Program code Listing A.3: 
35 <?xml version=" 1.0" encoding="UTF-8" ?> 
<GXML Version=" 1 .0.0.0"> 
<Head> 

<SceneDescriptor Name= n Scenel"> 
<SystemBitRate Variable="True n Minimum="0" Average="56000" Maximum="56000 , 7> 
40 <SystemLanguages Size="2">en-us no</ SystemLanguages> 

<SystemScreen Width="1024" Height="768" FrameRate="60.0" ColorResolution="32" 
Interlaced="FaIse"/> 

<SystemMachine Platform^'WH^" CPU="x86"/> 
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</SceneDescriptor> 
<SceneDescriptor Name="Scene2"> 
<SystemBitRate Variable="True" Minimum ="Q" Avera€e =,, 64000" Maximiim= H 64000 , 7> 
<SystemLanguages Size- '2">en-us no</ SystemLaaiguages> 
5 <SystemScreen Width="1024" Height="768" FrameRate= M 60.0" ColorResoluUon="32" 

Interlaced= M False , 7> 

<SystemMacliiiie Platform="Win32" CPU="x86"/> 
<ExternalURL>movie2 .gxml</ExteriialUE»L> 
</SceneDescriptor> 
1 0 <ImageDescriptor Name="IR_Image 1 "> 

<Pormat Type-'PNG" Width="5" Height^S" BitCount= ,, 24'7> 
<ExtemalURlr>movie2.gxml</Ext^maIUIlL> 
</ImageDescriptor> 
<ImageDescriptor Name="IR_Image2"> 
1 5 <Format Type="PNG" Width="5" Height="5" BitCount= M 247> 

<ExternalURL>iniage 1 . png</ExtemalUBiL> 
</ImageDescriptor> 
</Head> 
<Movie> 

20 

</Movie> 
</GXML> 



Program code listing A.4: 
25 <?xml version^' 1.0" encodiQg= ,, UTF-8" ?> 
<GXML Version="1.0.0.0 n > 
<Head> 
<Descriptors> 
<SceneDescriptor Name="Scenel"> 
30 <SystemBitRate Variable="True" Minimum= ,, O n Average="56000" Maxunum= M 56000'7> 

<SystemLanguages Size- '2">en-us no</ SystemLanguages> 

<SystemScreen Width="1024" Heiglit^VeS" FrameRate="60.0 M ColorResolutioii= ,l 32" 
Interlaced= ,, False , 7> 

<SysteiiiMachine Platform="Win32" CPU="x86'7> 
3 5 </SceneDescriptor> 

<SceneDescriptor Name="Scene2"> 
<SystemBitRate Variable= M True n Minimiini= , 'O n Average="64000" Maximum="640007> 
<SystemLanguages Size="2">en-us no</ SystemLanguages> 

<SystemScreen Width= n 1024" Height="768" FrameRate="60.0 M ColorResolution= H 32" 
40 Interlaced="FaIse , 7> 

<SystemMachine Platform="Win32" CPU= M x86 M /> 
</SceneDescriptor> 
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<ImageDescriptor Name="IE>_Iinagel"> 

<Format Type="PNG" Width="5" Height^'S" BitCount="247> 
</ImageDescriptor> 
<ImageDescriptor Name="IR_Image2 ,, > 
5 <Format Type="PNG" Width="5" Height="5" BitCount="24 M /> 

</ImageDescriptor> 
</Descriptors> 
<References> 

<Reference Name="Scene2 H >movie2.gxml</Reference> 
1 0 <Reference Name='TO_Imagel M >movie2.gxml</Reference> 

<Reference Name= ,, m__Image2">image 1 .png</Reference> 
</References> 
</Head> 
<Movie> 

15 

</Movie> 
</GXML> 

Program code listing A.5: 
20 <?xml version^' 1 .0" encoding="UTF-8" ?> 
<GXML Version=" 1.0.0.0"> 
<Head> 

</Head> 
25 <Movie> 

<Scene Name="Scenel"> 
<Layout AutoSize="0" Width="550" Height= ,, 400 ,, /> 

<Appearance AntiaJias= n false" BackColor="#000000" BackStyle="opaque" 
Cursor^'arrow" FramesPerSec^S.O" QuaJity= H Mgli M /> 
30 <Image Name="Image 1 " Resource="IR_Image 1 "> 

<Layout Left="20" Top="20" Width= M 5" Height="5" Rotation= M 07> 
<Behavlor Enabled="true" Visible="true"/> 

<Appearance Cursor="arrow" Transparency= ,, 0" BackGolo^'^OOOOOO" 
BackStyle= n opaque M /> 
35 </Image> 

<Text Name= M Textl n > 
<Layout Left="40" Top="20" WidthF"100" Height="100 M Rotation^'O"^ 
<Behavior Enabled="true" Visible- 'true7> 

<Appearance Cursor="arrow" Transparency= ,, 0" BackColor- '#000000" 
40 BackStyle="opaque"/> 
<Data> 

<P><Font>Hello World !</Font></P> 
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</Data> 
</Text> 

<Program Resource-"" SrcURL=""> 
<Base64BinaiyData^00 
5 OOOOOOOOOnmOOOOOimnOOOOOOOOOimnODGm 
00000000000</Base64BinaryData> 
</Program> 
</Scene> 
</Movie> 
10 </GXML> 

Program code listing A.6: 
<?xml version= M 1.0" encoding="UTP-8 M ?> 
<Diddle xmlns="diddle.xsd" 
1 5 xmlns:gxml="gxml.xsd M > 
<Contalner> 
<Descriptor> 
<Statement Type="text/xml"> 
<gxml:GXML> 
20 <gxml:SceneDescriptor Name="Scenel"> 

<gxml:8ystemBitRate Variable="True M Minimum="0" Average-" 56000" 
Maximum="56000 , 7> 

<gxml:SysteinLaiiguages Size="2">en-us no</gxml:SystemLanguages> 
<gxml:SystemScreen Width="1024" Height="768" FrameRate="60.0 n 
25 ColorResoluUon="32" Interlaced="Faise"/> 

<gxml:SystemMachine Platform= n WirL32 n CPU="x86'7> 
</gxml:SceneDescriptor> 
<gxml:ImageDescriptor Name- TR Jmage 1 " > 
<gxml:Format Type="PNG" Width="5" Height= M 5 M BitCount="24"/> 
30 </gxnil:ImageDescriptor> 

<gxml:ImageDescriptor Name="IR_Image2"> 
<gxml:Format Type-'PNG" Width="5" Height="5" BitCouiit="24"/> 
<Ima£eLocator><MediaUri^ 
</gxml:ImageDescriptor> 
35 </gxml:GXML> 
</Statement> 
</Descriptor> 
<Item> 
<Component> 
40 <Resource Type= n text/xml"> 

<gxml:GXML> 
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<gxml:Scene Name= M Scenel"> 
<gxml:Layout AutoSize= M 0" Width="550" Hei£ht="400"/> 

<gxml:Appearance AntiaJias= M false" BackColor="#000000" BackStyle^'opaque" 
Gursor="arrow" FramesPerSec="25.0" QuaUty^ M Mgh'7> 
5 <gxml:Image Name="Imagel" Resource="m_Image 1 "> 

<gxml:Layout Left="20" Top="20" Width= n 5" Height="5" Rotation="0 B /> 
<gxml:Behavlor Enabled="true" Visible="true"/> 

<gxml:Appearance Cursor-'arrow" Transparency^"0" BackColor="#0000O0" 
BackStyle="opaque"/> 
10 </gxml:Image> 

<gxml:Text Name="Textl ,, > 
<gxml:Layout Left="40" Top="20 M Width="100" Height^'lOO" Rotation="0 M /> 
<gxml:Behavior Enabled="true" Visible- 'true7> 

<gxml:Appearance Cursor-'arrow" Traiispa^ency^'O" BackColor="#000000" 
1 5 BackStyle="opaque"/> 

<gxml:Data> 

<P><Font>HeUo World !</Font></P> 
</gxml:Data> 
</gxml:Texb> 

20 <gxml:Program Resource-"' SrcURL=""> 

<MediaIData64>00000000 
OOOimnOOOOOinmOOOOOOOO 
0000</MediaData64> 
</gxml:Program> 
25 </gxml:Seene> 
</gxml:GXML> 
</Resource> 
</Component> 
</Item> 

30 <Item ID="IR_Imagel M > 
<Component> 
<Resource> 
<ImageLocator> 
<InlineMedia type^'image/png 4 ^ 
3 5 <MediaI3ata64>00000 

OOCtoimOOOOOiumOOOOOOOOOimnOiumCto^ 
00000</MediaData64> 
</InliiieMedia> 
</ImageLocator> 
40 </Resource> 
</Component> 
</Item> 
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</Conteiner> 
</Diddle> 
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APPENDIX B 

This appendix shows the classes used by the program instruction code to control the 
playback. 

5 public class Scene 
{ 

public final static native int getWidth(); 
public final static native int getHeight(); 
public final static native void playScene(String name); 

10 } 



public class Image 
{ 

1 5 public int getLeft() ; 

public void setLeft(int value); 

public int getTop(); 

public void setTop(int value); 

public int getWidth(); 
20 public void setWidth(int value); 

public int getHeight(); 

public void setHeight(int value); 

public float getRotation(); 

public void setRotation(float value); 
25 public boolean getEnabled(); 

public void setEnabled(boolean value); 

public boolean getVisible(); 

public void setVisible(boolean value); 

public float getTransparency(); 
30 public void setTransparency(float value); 

} 



public class Text 
35 { 

public int getLeft(); 

public void setLeft(int value); 

public int getTopQ; 
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public void setTop(int value); 

public int getWidth(); 

public void setWidth(int value); 

public int getHeight(); 

public void setHeight(int value); 

public float getRotation(); 

public void setRotation(float value); 

public boolean getEnabled(); 

public void setEnabled(boolean value); 

public boolean getVisible(); 

public void setVisible(boolean value); 

public float getTransparency(); 

public void setTransparency(float value); 

} 



public class Mesh 
{ 

public int getLeft(); 

public void setLeft(int value); 

public int getTop(); 

public void setTop(int value); 

public int getWidth(); 

public void setWidth(int value); 

public int getHeight(); 

public void setHeight(int value); 

public float getRotation(); 

public void setRotation(float value); 

public boolean getEnabled(); 

public void setEnabled(boolean value); 

public boolean getVisible(); 

public void setVisible(boolean value); 

public float getTransparency(); 

public void setTransparency(float value); 

} 



public class Video 
{ 

public int getLeft(); 

public void setLeft(int value); 
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public int getTop(); 

public void setTop(int value); 

public int getWidth(); 

public void setWidth(int value); 

public int getHeight(); 

public void setHeight(int value); 

public float getRotation(); 

public void setRotation(float value); 

public boolean getEnabled(); 

public void setEnabled(boolean value); 

public boolean getVisible(); 

public void setVisible(boolean value); 

public float getTransparency(); 

public void setTransparency(float value); 

} 
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